Access management is highly desirable in connection with granting access to a digital resource such as a digital service or digital content, which may include digital audio, digital video, digital text, digital data, digital multimedia, etc. The resource can be the aforementioned content or the like, a server or the like having a library of content or the like, or any other or digital repository of information that a user might wish to access such as for example an electronic mail server, a gaming server, a network access server or point, etc. Likewise, the resource can be a service, such as a printer, a compiler, a renderer, or the like.
Typically, in an access management context, a requestor is granted access to a resource upon presenting a request with a security token identifying the requestor where this identity information allows one to determine the rights the requestor has with respect to the resource based on local authorization policy, among other things. In other systems, the security token may include an authorization expression directly which determines the rights the requestor has with respect to the resource, among other things. For example, the security token may comprise a digital certificate issued to and identifying the requestor and the rights thereof. In any event, the security token is typically issued to the requestor by an issuer that is known to and trusted by the resource. For example, within the context of an organization, the resource may be a data server, and the issuer may be an identity server set up by an administrator to provide an identifying security token to each member of the organization. Note, though, that the issuer may also be an identity server external to the organization and acceptable to the resource.
Typically, the resource includes or is accessed by way of an access control policy engine or the like that initially receives the request with the security token and decides based on the security token and perhaps other information whether the requestor is entitled to access to the requested resource. Upon satisfying itself that the requestor is in fact so entitled, the access control policy engine forwards the request to the resource for response thereby. For example, if the request is for a data file from the resource, the resource provides such data file, and if the request is to review information available from the resource, the resource allows the requestor to in fact review such information.
Notably, in at least some instances the resource provides data to the requestor. If so, the resource may choose to encrypt the data according to a format that allows the requestor to decrypt same, but not others. For example, it may be that the presented security token of the requestor is a digital certificate that includes a public key associated therewith, and the resource encrypts the provided data according to the public key of the presented security token. Thus, the requestor may apply a corresponding private key associated with the digital certificate to the encrypted data to reveal same.
Also notably, the resource may choose to attach terms and conditions to the encrypted data that the requestor must abide by. If so, and again presuming that the presented security token of the requestor is a digital certificate that includes a public key associated therewith, the resource may encrypt the provided data according to a selected symmetric key, encrypt the symmetric key according to the public key of the presented security token, and place the encrypted symmetric key and the terms and conditions in a digital license. Thus, the requestor may apply the corresponding private key associated with the digital certificate to the encrypted symmetric key of the license to reveal same, and then apply the decrypted symmetric key to the encrypted data to reveal same, presuming of course that the terms and conditions in the license so allow.
The security token accompanying a request for access to a resource may take any of several forms, especially if the resource is being accessed by a diverse group of requestors. Thus, the security token as received by an access control policy engine for the resource may be any of several types, such as for example an X.509 certificate, a Kerberos ticket, an XML-based digital certificate, a SAML token, an ISO MPEG REL license, or the like. The security token may indeed be simply a username with a corresponding password.
At any rate, the access control policy engine (access control policy engine) for a resource should be able to handle any of a plurality of types of received security tokens and be able to process same. Of course, dealing with multiple types of security tokens adds complexity to the access control policy engine, especially if the access control policy engine does not operate based on account-based information but instead must judge whether to grant access in connection with a request based primarily on the content of the security token or tokens accompanying such request.
That is, with the continued evolution to a globally interconnected world and complex distributed applications, account-based access is not considered adequate. As may be appreciated, in such account-based access, a requestor would create an account with or available to the access control policy engine prior to issuing a request to same, and the access control policy engine in deciding whether to grant access based on a request would refer to such account. Instead of account-based access, then, an access control policy engine may need to grant access based on a request from a requestor with which the access control policy engine has no prior established relationship, relying only on the security token proffered with the request from such requestor and identifying same. Presumably, then, the security token includes therewith at least some information that the access control policy engine may employ in deciding whether to grant access based on the request on a variety of identifying information in making these decisions. To deal with these realities, a variety of security tokens types are now commonly in use. Notably, the aforementioned, X.509 certificate, the SAML token, and the ISO MPEG REL license are examples of security tokens that can be used when a requestor and the resource with the access control policy engine may not have a prior established relationship.
Unfortunately, each type of security token format evolved as an independent standard, designed to address specific types of problems and having a disparate encoding format, information carrying capabilities, and semantics. In addition, each type of security token was introduced into computing environments in an incremental fashion. Thus, rather than being able to deal with only a single type of security token, an access control policy engine must instead have an interface for manipulating each type of security token to expose and employ the information contained with such type of security token. As may be appreciated, then, adapting an access control policy engine to accept a new type of security token is costly and difficult. Alternatively, and perhaps worse, an access control policy engine must assume that requestors will be using a specific type of security token.
Of course, either situation creates difficulties in adapting to new business models, evolving to support new relationships between organizations and individuals, handling dynamic relationships, taking into account richer information about a requestor in making an access decision, and providing seamless scalability. For example, an access control policy engine originally designed assuming enterprise account-based security tokens cannot easily adapt to handle security tokens for requestors outside the enterprise. Similarly, an access control policy engine designed to use X.509 security tokens cannot easily move to support Kerberos, SAML or REL security tokens.
Existing approaches to addressing such problems have had limited success. The most common approach has been for the access control policy engine to force all security tokens to map to locally managed accounts, where the access control policy engine then makes each access control decision based solely on a corresponding local account. However, it is to be appreciated that it is costly for an access control policy engine to maintain local accounts for external entities, often with transient business relationships. Moreover, relying on local accounts means that any rich semantics or data encoded in a security token are lost in doing the translation to the corresponding local account. It also fails to provide support for evolving business needs in which an administrative entity determines the allowed access for a requestor and encodes that information directly into a security token which is presented to the access control policy engine. At any rate, forcing semantics not intended for accounts, such as mapping application or organization identify to a user account, creates semantics problems that can affect manageability.
Another approach has been for the access control policy engine to include multiple paths, each which handles a specific security token format. In such a situation, however, only a single type of security token can be handled per request and any unification across types is based on application specific logic. The net result is duplicative effort and lack of a common unification paradigm that supports common access control policies.
Accordingly, a need exists for a new type of access control policy engine that can control access to a resource based on any of multiple received types of security tokens, and without the need for local accounts or multiple paths. In particular, a need exists for such an access control policy engine that maps the information in each of one or more types of security token received with a request to a common access-decision format, and that then decided whether to grant access based on the commonly formatted access-decision information. Further, a need exists for such an access control policy engine that handles mapping each type of security token based on a corresponding mapping module, whereby the access control policy engine can accommodate a new type of security token based on a corresponding new mapping module.